For IT organizations to enable business agility, they must ensure that enterprise applications are not only high-performance business engines driving efficiencies, but also that they become flexible building blocks of future business systems. One exemplary solution to achieve this goal is the use of a Service Oriented Architecture (SOA). SOA refers to a software architectural framework that may use loosely coupled or decoupled services that communicate and pass information between applications, modules, or components within the framework. For example, the SOA may include decoupled processing components or even deployment units, which may consist of one or more processing components. One implementation example of an SOA is the Enterprise SOA developed by SAP AG of Walldorf, Germany. In particular, the ESA is implemented through SAP NetWeaver, an integration and application platform, also developed by SAP AG. Other examples of SOA enabling platforms are .NET developed by Microsoft and Web Sphere developed by IBM.
A service of an SOA may represent a self-contained, self-describing piece of application functionality that can be found and accessed by other applications. A service may be self-contained, because the application using the service does not have to depend on anything other than the service itself, and may be self-describing, because all of the information on how to use the service can be obtained from the service itself. The descriptions may be centrally stored and accessible through standard mechanisms to all applications that would like to invoke the service. Because services may be generally granular in nature, services may be aggregated, and thus form building blocks for the task of automating enterprise-scale business scenarios.
Invoking a service typically involves the service's interaction and manipulation of data, specifically data in the form of business objects, stored within a repository or database. The term business object when used in an SOA represents a physical or logical object, such as a sales order. The description and creation of a business object may be accomplished through the use of metadata. Metadata, in general terms, may be described as data that describes other data.
Within an SOA, deployment units may contain business objects that process data. Further, each deployment unit may process data that is copied and sent from another deployment unit. For example, an SOA business application may manage inventory data. The application may have a first deployment unit for handling sales order data and a second deployment unit for handling accounting data based on the sales order data provided by the first deployment unit. As described above, in an SOA and other types of frameworks, the two deployment units may be decoupled. For instance, as discussed, the first deployment unit may continue processing after sending data for receipt by the second deployment unit, independently of whether or not the second deployment unit successfully received the sent data.
As noted above, the sent data may be based on data copied by the first deployment unit. In some situations, the sending deployment unit may not know if the message was ever received or whether the receiving deployment unit processed it correctly. The data sent by the first deployment unit, therefore, may not be consistent with any data received by the second deployment unit, if it was received at all. This data inconsistency, in turn, may compromise the accuracy or integrity of the data handled by the second deployment unit. In an inventory management system, such data inconsistencies can cause numerous problems, ranging from distorting perceived inventory levels to creating errors on reported financial information. Ensuring the consistency of the data operated on or output by each deployment unit is thus extremely important.
Verifying the consistency of data is also important for software application systems other than one implemented in an SOA. In particular, many types of software applications may copy data to create data for use in other parts of the application. This may occur, for example, in legacy systems, stand-alone applications, etc. When the data is copied in such systems, errors may be introduced as part of the process performing the data copying. Accordingly, there is thus a need for a way to ensure the consistency of data that is copied in a software application system for use by other parts of the system.